There's been quite the discussion about protecting your machine, stuff like >>>> Are you going to write a program that checks to see if root's >>>> cronjob has been modified? >>> I suppose if you really wanted to make sure that crontab entries >>> couldn't be changed is to put them on a write protected floppy, >>> mounted at boot. >> The best thing to do is to run tripwire from a read-only device >> (like a floppy) > What is to stop someone from mounting another filesystem over the top > of your tripwire database and crontab entries. Replace the mount and > df commands to not show the new mount point. > You really need to do a seperation of the checkee from the checkor. > If someone has root access on the machine, the could basicly do > anything that is needed to cover their tracks. If I might offer a suggestion: - Your "system" stuff is on a pack with physical write-protect (many, perhaps most, disks have a write-protect jumper; it's just a question of bringing it out to a switch on the housing). This includes boot device and all "system" filesystems (/, /usr, etc). - All remaining (read/write) filesystems are mounted noexec, and your logfiles are set append-only. - When you want to update an executable, you (a) power off the machine, (b) disconnect its netlink, (c) flip the write-protect switch, (d) boot, (e) do your changes, (f) power off, (g) flip the write-protect switch back, (h) reconnect the net, and (i) come back up. I'm going to (once I have the disk to do so) set up a strongbox machine using just such a scheme. With the hard write-protect, you know that even if an attacker somehow gets a fully-powered root shell, your basic system _can't_ be destroyed or trojaned, and that includes the mount table (since it's on your boot pack). All the attacker can possibly damage is the logfiles on the writable pack, and even that would require breaking the kernel to the extent of being able to sidestep the append-only bit. (I'm assuming, of course, a system that _has_ append-only files, and won't let the append-only bit be cleared unless you're in single-user mode, something like what NetBSD does.) The noexec mount points for the read/write pack are to make it harder to trip over trojans left lying around there. Obviously, as I have outlined it, this is not acceptable for a machine with users on it, if only because users normally expect to be able to run their own executables. If you drop the noexec part, it might be workable for a machine with users; the physically read-only system pack still makes it highly resistant to trojaned versions of things like ps, ls, du, or even the kernel. Of course, you need the discipline to never write-enable it without bringing the machine down first and disconnecting it from the net, but if you can't handle that you have a human problem much more serious than any technical problem. :) You also need a system that can run with read-only "system" filesystems. Some systems make this easier than others. I've done it with NetBSD (with root on nfs rather than local disk); I suspect most systems can tolerate it with a little creative symlinking if necessary. der Mouse mouse@collatz.mcrcim.mcgill.edu